System And Method For Integrating Trading Operations Including The Generation, Processing And Tracking of Trade Documents

ABSTRACT

First and second components of the present invention, in combination, provide a customer interface for initiating a trade transaction and provides for the secure viewing of the status of the transaction. A third component assists in the automatic generation and verification of the voluminous and detailed documents required to support a trade transaction. The third component additionally tracks and assists in the management of the seller&#39;s manufacturing and shipment of the goods that form the basis of the trade transaction. A fourth component automatically generates a Letter of Credit from a Purchase Order and performs a reconciliation function on payments made pursuant to Letters of Credit or open Accounts.

RELATED APPLICATIONS

This application is based on and claims priority to U.S. ProvisionalPatent Applications Nos. 60/113,561, filed Dec. 23, 1998; 60/113,643,filed Dec. 23, 1998; and PCT Application No. PCT/US99/26672, filed Dec.11, 1999, the entire disclosures of which are hereby incorporated byreference.

FIELD OF THE INVENTION

The present invention generally relates to systems and methods formanaging trading operations and more particularly to a system and methodfor generating, processing and tracking documents and processesassociated with import/export trading operations.

BACKGROUND OF THE INVENTION

Presently, the process of documenting a trading operation between abuyer and a seller is manually intensive and error prone. Typically, atrading operation begins with a buyer wanting to purchase goods from aseller and requesting a price quote for the goods. The buyer and sellernegotiate the terms of the trade resulting in the price quote as well asthe other terms and conditions the two parties agree upon as being thebasis of the agreement. The buyer then issues a purchase order (PO) tothe seller reflecting the agreed upon price quote and the terms andconditions. The PO specifies the essential components of the transactionsuch as the type, amount and price of the goods as well as other detailssuch as the time and place of delivery. Although not always required,the next step in the traditional process is the issuance of a Letter ofCredit (L/C) by a bank. The L/C is generated from and typicallyincorporates all of the agreed upon terms and conditions and all of thePO information. The L/C is essentially a guarantee of payment by thebank that issued the L/C (the issuing bank) if the seller complies withall of the terms and conditions of the L/C. Specifically, as banks dealin documents and not goods, the seller must present a complete set ofdocuments that strictly comply with the L/C in order for the issuingbank to honor the L/C. The L/C is issued by the issuing bank based uponthe credit worthiness of the buyer.

The PO and/or L/C is transferred to the seller who is then in a positionto manufacture (or supply) and ship the goods requested by the buyer.Internally, upon receipt of the PO and/or L/C, the seller creates aSales Order in order to document the sale. The Sales Order reflects therequirements of the PO and/or L/C. If the seller is a manufacturer, theSales Order is used to generate a manufacturing specification sheet fromwhich the actual goods are manufactured. If the seller is a distributorthe Sales Order is used to generate a warehouse pick slip that is usedto pick the goods to be shipped. Alternatively, the seller can use thePO and/or L/C from the buyer to generate its own PO that is issued tothe actual manufacturer of the goods. Once the manufacturing process issufficiently complete, the seller contacts a shipper/freight forwarderto arrange for the shipment of the goods. The seller sends the shippershipping instructions from which the shipper generates a Bill of Ladingand customs documents (if required).

When the seller has the goods available for shipment (either throughmanufacturing, picking from the warehouse or acquisition from themanufacturer) the seller generates all of the documents required by thePO and/or L/C. These documents typically include an invoice for thegoods, packing slip, certificate of analysis and/or origin.Additionally, the seller at this point provides for the transportationof the goods, procures shipping insurance and files the required tradedocumentation with both the origin and destination governmentauthorities. Once the goods have been shipped, all of the tradedocuments required by the PO and/or L/C are presented for negotiation tothe issuing bank (or another negotiation bank acting on the issuingbank's behalf).

As is readily seen from the above description, the process required todocument a trading operation involves many parties generating manydocuments from the same redundant purchase information from the buyerthat is entered in the systems of the bank, the seller and other tradingpartners, and is therefore susceptible to error and grossinefficiencies. These errors in the documentation lead to delaysthroughout the process including delays in the shipment of the goods.Any such errors result in the delay of receipt of the goods by the buyerand delay of receipt of payment by the seller. It is clear that all ofthe parties to the transaction would benefit from a system and methodwhich reduces the number of errors in the documentation.

Since this documentation process is not part of an exporter's or animporter's core business (i.e., buying and selling goods) many exportersand importers are now outsourcing the documentation and trackingoperations to third parties. Furthermore, since there is a certain levelof risk exposure in the letter of credit collection process, manycustomers are looking to banks to assist them in their letter of creditfund collection.

SUMMARY OF THE INVENTION

In light of the above limitations of the prior art systems and methods,it is an object of the present invention to provide buyers, sellers,trading partners, their global affiliates, agents and supply chainservice providers (e.g., shippers) with an automated facility in whichall of the information associated with a trade is electronicallyexchanged and accessed via the Internet, third party network (ValueAdded Network, VAN), leased line or through dial up connection.

It is a further objective to automatically generate the documentationrequired for the trade from the trade agreement or instrument (e.g.,Letter of Credit or Purchase Order).

It is also an object of the present invention to assist exporters(sellers) in monitoring their contractual agreements, assist in managingtheir production of goods and managing their risk exposure as well asproviding an exporter with integrated treasury management services.

It is additionally an object of the present invention to assistimporters (buyers) in monitoring their contractual agreements (e.g.,outstanding obligations under Letters of Credit), providing informationto assist in managing their inventory, and managing their contingentliability as well as providing an importer with integrated treasurymanagement services.

In a preferred embodiment, the systems and methods of the presentinvention are operated and executed by a bank, but in practice, portionsof the systems and methods can be operated and executed by any party.Although the present description of the present invention is made withrespect to a bank, it should not be interpreted to be limited to abanking environment.

The present invention consists of four main components, TradeEDI, TradeManager, TradeDoc and a Financial System. TradeEDI provides anelectronic interface and gateway (e.g., secure Internet connection) tothe system for customers. Trade Manager provides a customer interfacefor initiating and tracking of the status of a trade transaction.TradeDoc is primarily used on behalf of exporters(sellers/manufacturers) and supply chain service providers to assist inthe generation of the voluminous and detailed documents required tosupport a trade transaction as well as to track and assist in themanagement of the seller's manufacturing/picking/procurement andshipment of the goods that form the basis of the trade transaction.

The trading operation is typically started by a buying party who is acustomer of the bank. The buyer transmits a Purchase Order (PO) and/orLetter of Credit (L/C) application utilizing either Trade EDI or TradeManager. The PO and/or L/C is transmitted either by electronic means orby paper (which is then keyed in or scanned at the bank). The PO and/orL/C represents the terms and conditions that the buyer and seller haveagreed upon as governing the trade transaction (e.g., type and quantityof goods, unit price, delivery date and place . . . ) If requested, thesystem of the present invention can automatically generate an L/C from asupplied PO. Such a generated L/C goes through the normal approvalprocess within the bank.

Once the PO and/or L/C is verified against the customer's profile, it ismapped into a database in the Financial System which in turn feeds adatabase maintained by Trade Manager. The database can either berelational, object oriented or a combination of both. From this pointforward in the entire trade process, all of the parties to the tradetransaction are able to log onto Trade Manager and quickly determine thestatus of any particular trade operation. In a preferred embodiment ofthe present invention, users employ a standard browser and the Internetto communicate with Trade Manager. Standard security techniques such asencryption and authentication and non-repudiation are used to provideconfidential communications and to ensure proper identification of theparties over the Internet an other electronic communication media. Theuse of the Internet is an incredible advantage of the present inventionsince most trading operations involve parties which are distributedworldwide. For example, the buyer might be in Texas, the seller might bein Singapore, the buyer's bank might be in New York and the seller'sbank might be in London. Using the present invention. Any of the partiescan access Trade Manager 150 through the Internet and instantly find outthe status of the trade operation. Additionally, TradeEDI can exchangethe information (e.g., push the information) via an electronic messagethrough the Internet or other communication media to the buyer seller ortheir respective trading partners as the trade transaction is beingprocessed in the Financial System or TradeDoc.

The other significant part of the present invention is TradeDoc. Asdescribed above, in the traditional prior art approach, all of thedocumentation related to the trade transaction was generated manuallyfrom paper files. This manual generation is significantly laborintensive and error prone. As often said, the devil is in the details.Unfortunately, an error in the details with respect to a trade operationcan extremely costly both in terms of delayed or lost revenues, but moreimportantly from a relationship point of view between a buyer and aseller. Even if a seller has significantly better products, buyers arenot willing to deal with the seller if the seller cannot manage theadministrative details of the documentation a deliver the requestedgoods on time. The present invention solves all of these problems of theprior art by automatically generating a verifying all of thedocumentation at each step of the seller process.

TradeDoc is a facility that can generate trade documents in accordancewith the terms and conditions of an L/C or PO (in an Open Accounttransaction). TradeDoc's facilitates trade document processing forglobal supply chain customers where the buyer is customer of the bankand the seller may or may not be a customer of the bank. Trade Doc alsogenerates the proper trade documents in a trade transaction for theseller when the seller is a customer of the bank and the buyer may ormay not be a bank customer. TradeDoc maintains a comparable database tothat maintained by Trade Manager and is therefore capable of generatinga Sales Order for seller using the details contained in the L/C and/orPO. Alternatively, if the seller generates the sales order itself,TradeDoc compares the Sales Order to the L/C or PO to verify itsaccuracy. In a similar fashion, TradeDoc is capable of either generatingor verifying manufacturing specification sheets, invoices, shippinginstructions, insurance instructions, drafts, beneficiary certificatesand Bills of Lading and virtually any other trade documents required forthe seller to satisfy the L/C or PO. As the generation and verificationoperations performed by TradeDoc are all executed from the initiatedpurchase information of the L/C and/or PO in the same common database,all of the opportunity for error in the documentation is eliminated.Once the manufacturing has been completed and the goods are ready forshipment, TradeDoc generates all of the final export documents requiredto complete the transaction. TradeDoc can remotely print the completeddocuments at a location closest to the buyer or the buyer's bank tofacilitate the collection process. In an alternative embodiment, all ofthe trade documents are transmitted to the receiving partnerelectronically. This embodiment is becoming more and more prevalent inelectronic commerce transactions (e.g., electronic marketplace).

Each of TradeDoc, TradeEDI and Trade Manager are integrated systems thatallow the customers of the bank to permit their trading partners to viewthe trade documents. Trade Manager provides viewing of trade documentsgenerated by TradeDoc on a browser via the Internet. Based on thecustomer's profile, some trading partners are provided with theauthorization to print documents. TradeEDI can receive or sendelectronic documents to trading partners based on the agreement of thecustomer which s reflected in the customer's profile.

The present invention further provides reconciliation functions for boththe buyer and the seller. When the trade documents are presented fornegotiation, the system informs the buyer's accounts payable systems ofthe payment and correlates the invoice from the seller to the L/C or POissued by the buyer. Similarly, when a payment is received from theybuyer, the present invention is capable of performing a reconciliationprocess by which the payment is reconciled against the seller's accountsreceivables (e.g., invoiced items). In this manner the present inventionis able to assist in every aspect of the trading operation, frominitiation to collection while solving all of the above describedproblems of the prior art.

BRIEF DESCRIPTION OF THE DRAWINGS

For the purposes of illustrating the present invention, there is shownin the drawings a form which is presently preferred, it being understoodhowever, that the invention is not limited to the precise form shown bythe drawing in which:

FIG. 1 illustrates the main components of the system of the presentinvention;

FIG. 2 depicts an overview of the functions performed by the variousportions of the system of the present invention;

FIGS. 3A and 3B illustrates process executed by the TradeDoc componentof the present invention; and

FIG. 4 depicts the payment and reconciliation functions performed by thepresent invention.

DETAILED DESCRIPTION OF THE INVENTION

FIG. 1 illustrates the main components and dataflow of the system andmethod of the present invention. Element 100 is the TradeDoc elementwhich includes the facilities for trade document preparation andgeneration. Element 150 is the Trade Manager element which providestracking and communication services throughout the entire trade cycle.Element 125 is TradeEDI provides the electronic gateway and interface tosecured exchange of information among customers and their tradingpartners via the Internet or other electronic communication media.Element 175 represents the Financial System 175 of a financialinstitution such as a bank. The Financial System 175 provides thetradition financial processing services such as the approval andgeneration of a Letter of Credit (L/C) or Open Account transaction andthe payment and receipt of funds pursuant to the L/C or Open Account.Elements 120 and 130 respectively represent the Seller 120 and Buyer 130in the trade transaction.

In a preferred embodiment, each of TradeDoc 100, Trade Manager 150 andthe Financial System 175 is hosted and operated by a financialinstitution (e.g., a bank) and consist of a combination of software andhardware. Due to the scalability and various processing models (e.g.,satellite and hub processing or distributive processing), FinancialSystem 175 can be implemented using either client server mainframeprocessing. The client server technology can use Internet web technologysuch as SUN Javasoft or Netscape Web Server, Java servlets, HTML/XML andJava for presentation and CORBA technology allows the processingapplication servers located at various sites to communicate with eachother. This netcentric technology allows remote branches with limitedtelecommunication bandwidth to access and initiate transactionalinformation. In addition, the hub site can process using either UNIX orPC/NT servers using the C++ programming language and relationaldatabases (e.g., Sysbase, Oracle or other similar relational databasetechnology) to handle transaction processing and Visual Basic and VisualC++ on client workstations at the hub site. Alternatively, FinancialSystem 175 can be implemented using traditional mainframe computersystems such as an IBM System 390. In each embodiment, the softwareoperating as part of Financial System 175 includes custom softwaredesigned to carry out the functions described herein. In the bankingenvironment, the Financial System 175 can include one centrally locatedfacility or several geographically dispersed facilities such as in NewYork and London.

TradeDoc 100, TradeEDI 125 and Trade Manager 150 can be constituted bysoftware executing on one or more mainframe systems or on one or moreserver systems. A mainframe system is one as described above withrespect to the Financial System 175. In one embodiment of the presentinvention, TradeDoc 100, TradeEDI 125 and Trade Manager 150 operate onthe same mainframe system as the Financial System 175. In a preferredembodiment of the present invention, TradeDoc 100, TradeEDI 125 andTrade Manager 150 utilize the same netcentric technology as describedabove with respect to the Financial System 175. Sun Javasoft or NetscapeWeb Server, Java servlets, HTML/XML and Java for presentation and CORBAtechnology for remote sites' application servers to communicate witheach other. The application servers use commercially availablenetcentric technology with CORBA (e.g., WebLogics and Websphere).TradeEDI employs a commercially available EDI translator (e.g.,Harbinger's OpenEDI, Gentran or others). Trade XML messages are used tofacilitate message communications between the Financial System 175 andTrade Manager 150, TradeDoc 100 and TradeEDI 125. In each of theembodiments, Trade Manager 150, TradeEDI and TradeDoc 100 includescustom software programmed as described herein using the above describedcommercially available software.

In one embodiment, Financial System 175, Trade Manager 150 and TradeDoc100 communicate with each other as illustrated in FIG. 1 by means of acorporate intranet. As the communications between Financial System 175,Trade Manager 150 and TradeDoc 100 involve sensitive financialinformation, the channels of the communication in the corporate intranetlinking must provide a proper level of security. As is furtherillustrated in FIG. 1, both the Seller 120 and Buyer 130 eachcommunicate with Trade Manager 150 and TradeDoc 100 through TradeEDI125. In a preferred embodiment, the communication media between theSeller 120 or Buyer 130 and Trade Manager 150 and TradeDoc 100 is thepublic Internet. In this embodiment, the Seller 120 and Buyer 130 areeach able to communicate with the system of the present invention usinga standard Internet browser such as Netscape™ Navigator™ or Microsoft™Explorer™, with TradeEDI 125 providing the proper encryption,authentication and non-repudiation required for secure financialcommunications. Alternatively the Seller 120 and Buyer 130 can connectto Trade Manager 150 or TradeDoc 100 using a leased line, third partynetwork, or dial up line, again using TradeEDI 125 as the interface forsecure communication.

The workstations employed by the Seller 120 and Buyer 130 are preferablyany Internet ready device (e.g., personal computers (PCs), cellularphones with Internet capability or Personal Digital Assistants (PDAs)(hand held devices) that are Internet ready such as 3Com Palm V or VII).Alternatively, the Seller 120 and Buyer 130 workstations can be part ofserver or mainframe network system operated by or for the Seller 120 orBuyer 130. It will be recognized that the buyer and seller as well asother supply chain parties' workstations will contribute additionalfunctionality to the processes associated with emerging e-commercetechnologies such as virtual marketplaces (e.g. Intelysis, MySAP,SAPHIRE, and TradeMatrix.) As will be further described below, theSeller 120 and Buyer 130 workstations preferably communicate with one ormore of the respective general ledger, administrative, accounting andmanufacturing systems of the Seller 120 and Buyer 130.

As the communications between the Seller 120 and Buyer 130 on one sideand Trade Manager 150 and TradeDoc 100 on the other side includefinancial and other proprietary information, appropriate securitymechanisms are employed by TradeEDI 125 to protect these communications.In the direct dial and private network embodiments, security is enhancedby the private nature of the connection. In the public Internetembodiment though, extra security precautions must be taken. Thesesecurity measures include for example authentication, encryption andnon-repudiation. In authentication, Certifying Authority (CA) softwareis used to authenticate that information electronic communications arebeing sent by and received from the proper party without tampering andto further ensure that the communication cannot be repudiated.Furthermore, all communications are encrypted to prevent unauthorizedaccess to the data contained in the communication. In one embodiment,Public Key technology is used for encryption, authentication andnon-repudiation. As appreciated by those skilled in the art, theauthentication, encryption and non-repudiation systems operate inaccordance with the appropriate ANSI and ISO standards and guidelines.

FIG. 2 illustrates in more detail the components and the processes ofthe present invention. The are essentially three phases to the process,Initiation, Tracking and Payment. FIG. 2 illustrates the initiationphase when the buyer is a customer of the financial institutionoperating the system. In the first phase, an application for an L/Cand/or a PO from the Buyer 130 is received and processed by FinancialSystem 175. In the second phase, the goods are manufactured, picked orprocured and shipped, and all of the documentation required for thisprocess is generated by TradeDoc 100 as is further illustrated in FIGS.3A and 3B. In the final phase, payment and collection pursuant to theL/C or open account takes place. The payment process is furtherillustrated in FIG. 4. Each action in all of the phases is tracked byTrade Manager 150 which is accessible to all of the parties involved inthe transaction (as noted below, certain information in Trade Manager150 is accessible only to certain parties based on agreement between theparties).

As illustrated in FIG. 2, the process is initiated by the Buyer 130transmitting to the bank either a PO by itself, or a PO and anapplication for an L/C. In a preferred embodiment, the documents arereceived from the Buyer 130 in electronic form, either through theInternet or other electronic communication means. Alternatively, thedocuments can be received in paper form and manually keyed or scanned inby bank personnel. In one embodiment of the present inventionillustrated in FIG. 2, POs that are received from the Buyer 130 arestored (warehoused) by the Financial System 175 in a data warehouse 215for subsequent grouping by the customer's business rules into one ormore L/Cs. This is an attractive service to Buyer's 130 who do not wantto develop or purchase an L/C system to track and monitor their L/Cs andthe associated POs. As described above, certain trade transactions donot require an L/C and in these types of transactions the Buyer 130merely sends the PO which initiates an Open Account transaction in theFinancial System 175.

When electronic files are received from a Buyer 130, TradeEDI 125 (notshown in FIG. 2) translates the incoming data and utilizes thecustomer's profile contained in database 205 to map the data into theFinancial System 175. This translation and mapping is performed for bothL/C transactions and Open Account transactions. If the Buyer 130 hasrequested that the bank create an L/C from the PO, the L/C isautomatically generated by an Auto L/C module 225. Auto L/C uses the POinformation from the Buyer 130 and a preestablished customer profile forthe Buyer 130 contained in database 205. The profile for the Buyer 130contains standard L/C templates used by the Buyer 130 including standardL/C text and terms and conditions used for the particular Seller 100involved in the trade transaction. The L/C generated by the Auto L/C 225is customized based on the PO information and the buyer profile. Forexample, if the PO indicates a particular Seller 120, the Buyer 130 andSeller 120 can have a set of agreed upon terms and conditions which arereflected in the buyer profile. The terms and conditions with respect toa different Seller 120 might be different, and these differences arereflected in a different standard template for use with transactionsinvolving that Seller 120. Each of the templates are stored in the buyerprofile in database 205. Furthermore, different terms and conditions aregenerated depending on the goods, amounts, delivery dates . . .contained in the PO.

Financial System 175 provides for data validation utilizing thepre-established terms and conditions for the beneficiary (e.g., seller)and other parties contained in the Buyer's 130 profile in customerprofile database 205. The data from the customer profile 205 and theFinancial System 175 required data are compared to the incoming datafrom the Buyer 130 to ensure completeness and to meet the required UCPcode. If there are no discrepancies, the Financial System 175automatically performs a credit check with respect to the Buyer 130 andcreates the L/C in the Auto Release process 230 (also known as straightthrough processing). This process requires no manual processing. Ifthere are discrepancies found between the data from the Buyer 130 andthe data in the customer's standing profile 205, the Financial System175 sends the transaction to Repair 210 for manual review and potentialrepair or clarification with the Buyer 130. The Financial System 175highlights the discrepancies to ease the review process.

Once the discrepancies have been resolved, or if there are nodiscrepancies, Auto Release 230 updates each of the database in TradeManager 150 and if the Seller 120 is a part of the global supply chainnetwork of the Buyer 130, a customer, or a customer of the bank'strading partners, the information will be sent to TradeDoc 100 toreflect the status of the issued L/C. Trade Manager 150 notifies theSeller 120 (or its advising bank or other agent) of the issuance of theL/C by the which the Seller 120 can commence its manufacturing/picking,procurement and shipping operations.

As described above, certain transactions known as Open Accounttransactions do not require a L/C and the PO alone forms the initiatingdocumentation for the transaction. In this case, the PO is firstvalidated (for consistent and complete information as described above)and mapped by the Financial System 175 into its own internal databasefor Financial System 175 tracking purposes. Once this validation andmapping has been completed, the PO information is transmitted to TradeManager 150 and TradeDoc 100 for inclusion in the databases for thosemodules. Trade Manager 150 then notifies the Seller 120 (or its agent)of the issuance and receipt of the PO by the which the Seller 120 cancommence its manufacturing/picking, procurement and shipping operations.

In an alternative embodiment of the present invention, the Buyer 130 canuse a different banks to issue the L/C. In this embodiment, the Buyer130 can establish agreements with all its banking providers to useTradeEDI 125, Trade Manager 150 and TradeDoc 100 to service all of itstrade operations. The operator of the system of the present invention inthis embodiment is operating as an outsource contractor and does nothave any responsibility as an issuing or advising bank. In thisembodiment, the Buyer 130 would also establish similar agreement withits vendors to utilize TradeEDI 125, Trade Manager 150 and TradeDoc 100.This would allow the Buyer 130 to have all the purchase and paymentinformation in one location so that it can manage its global supplychain more efficiently. The Buyer 130 creates an electronic L/Capplication via either Trade Manager 150 or TradeEDI 125 and selects itsdesignated issuing bank. The L/C application and PO information ismapped and validated using the buyer's customer profile into theFinancial System 175. The complete L/C transaction is sent to TradeManager 150 to allow the issuing bank to review and approve thetransaction. The L/C data as well as the terms and condition can bedownloaded by the issuing bank to interface with its internal financialsystem. The approval process can be either a single or multi levelapprovals. The number of approvers can also depend on dollar amount ofthe L/C. Once the designated issuing bank approves the transaction onTrade Manager 150, the L/C is released and issued by the designated bankto an advising bank or to the Seller 100. If there is an advisinginvolved, the L/C will be sent by the Financial System 175 to thedesignated advising bank via SWIFT, Telex or mail. The issued L/Cinformation can be downloaded from Trade Manager 150 or be sent byTradeEDI 125 to the designated issuing bank to update their internalfinancial systems. The L/C information is made available only to the L/Cissuing bank and the Buyer 130. If the issuing bank and the Buyer 130have an agreement with the Seller 100 and other related tradingpartners, the L/C information on Trade Manager 150 can be also access bythese parties. The L/C and PO information are transmitted to TradeDoc100 for trade documents preparation and can also assist the Seller 100managing its L/Cs.

Regardless of whether the operative document is a PO or a PO or and L/C,all of the information from these documents is included in the TradeManager 150 database. The most significant part of Trade Manager 150 isa database (relational, object oriented or a combination of both),business rules and customer profiles which allows for data entry,amendment, query and viewing. In the preferred embodiment, each recordis based on an L/C and contains data with respect the following fields:L/C number, PO number, beneficiary name (e.g., Seller 120), beneficiaryaddress, beneficiary country, ship to party name (optional), ship toparty address (optional), goods description (optional), item number orstyle number (optional), color (optional), size (optional), shippingterm (optional), port of loading (optional), country port of loading(optional), port of destination (optional),country port of destination(optional), earliest ship date (optional), latest ship date, mode oftransportation (optional), quantity, units of measure for quantity,currency, unit price, unit of measure for unit price (optional ifdifferent from unit of measure for quantity) total amount, Buyer 130'sSKU number (optional), Seller 120's SKU number (optional),manufacturer's SKU number (optional), division number (optional), tenortype (optional), tenor day (optional), tenor code (optional), andstatus. The above list is not exhaustive and particular implementationsof the present invention may use more or less than the number any typesof above described data fields. Furthermore, the primary index of thepreferred database is the L/C, while other implementations can haverecords based on a PO.

Although the above discussion has referred to a single PO from the Buyer130, in practice, several POs (each PO containing multiple items) can becovered by a single L/C or be considered part of an Open Account tradingtransaction. Trade Manager 150 provides the customer's profile with itsassociated vendor profiles and customer business rules in order tocorrelate between an L/C and all of the POs covered by the L/C. The banktypically wants to keep track of the status of the trade operation froman L/C point of view (since the L/C is the operative financialdocument), while the Buyer 130 and Seller 120 are more concerned withthe status of the PO and its line items since these items represent thegoods. In order to accommodate the different parties, Trade Manager 150provides different views of the database. In a preferred embodiment,views are provided, by beneficiary (Seller 120) by L/C or by PO. Inaddition, a Buyer 120 may put more descriptive information on a L/C formerchandise inventory than contained in the PO in order to protectthemselves (e.g., fabric content, item category (i.e., toys), etc.).

In response to a query by a user (e.g., a Buyer 130) the records fromthe Trade Manager 150 database are displayed to the user in a tableformat. For example if Buyer 130 makes an inquiry of the Trade Manager150 database about all transactions involving beneficiary company XYZ(i.e., a Seller 120) Trade Manager 150 generates a tabular report thatlists, for every transaction with company XYZ, the PO number, the L/Cnumber, the quantity of goods, the unit price, the total PO amount andthe current status. It is appreciated that the information which can bedisplayed by Trade Manager 150 can be tailored to individual users. Forexample, a particular Buyer 130 might be more concerned with theproposed delivery dates than it is concerned about the unit price. Thesedelivery dates can easily be incorporated in the report for that Buyer130. As described above, in the preferred embodiment, similar tabularviews are available for sorting by L/C and/or PO.

In an aspect of the integrating TradeDoc 100 and Trade Manager 150, theSeller's 120 information can be made available to the Buyer 130. If theBuyer 130 and Seller 120 agree, information such as the manufacturer'sstatus information, shipping status information and other suchinformation can be made available to the Buyer 130 to monitor and track.This will allow the Buyer 130 to manage the inventory and thedistribution of goods or to potentially redirect a shipment in the eventof a change of circumstances.

One of the main tasks of Trade Manager 150 is to keep track of thehistory of the POs during the life of the respective L/C. If the PO orL/C is updated as a result of an amendment or payment, the value of therecord is not overwritten, but rather Trade Manager 150 createsamendment or payment record which is then linked back to the base POand/or L/C records. When viewing data from the Trade Manager 150database, the user is given the option to zoom in on a selected record.As the user zooms in, Trade Manager 150 displays the details of therecord, as well as the history (i.e., all amendments and payments). In apreferred embodiment, a running balance of both the quantity and amountis displayed under the history section.

Trade Manager 150 allows for file export by appropriately authorizedusers. Standard formats are supported such as ASCII, Excel™ and Lotus™files. The export can take place by any of the means described abovesuch as through the Internet or other private Electronic DataInterchange (EDI). The user can select from a list of all available dataelements and specify the order by which each of the data elements is tobe exported. Additionally, user can specify additional selectioncriteria such as date range, balance quantity or beneficiary. Tradedocuments, print files and electronic message associated with an L/C orPO transaction are available to be viewed by both the Seller 120, theBuyer 130, and other trading partners. Furthermore, Trade Manager 150supports scheduled downloads of information to a user. This feature isattractive for Buyers 130 and Sellers 120 who maintain internal systemswhich require updating by the information available from Trade Manager150. Trade Manager 150 also provides archiving services for its users.Typically a user would not want any records archived until the tradetransaction embodied in the records has been completed (e.g., expired,canceled or fully drawn).

As briefly described above, Trade Manager 150 provides several securitymechanisms to ensure confidential communications between the system andit users. These security mechanisms include encryption, authentication,non-repudiation. Furthermore, each user is provided with a profile whichincludes the data to which the user has authorized access. Naturally,Trade Manager 150 prevents a particular customer from viewing thetrading transactions of another customer. Trade Manager 150 provides afurther level of access security in which a customer can designate whichof its employees can view particular data. For example an exporter(Seller 120) can designate that its manufacturing employees may view thePO data but not L/C financial data associated with a trade transaction.In the preferred embodiment, all of the users (other than the bankpersonnel) have read only rights with respect to the data stored inTrade Manager 150. This security feature ensures that no one canintentionally, or more likely, unintentionally alter the data containedin the database. If a user discovers an error or other discrepancy inthe database, the bank operators are notified and have the ability tomodify the data to correct the error.

As described above, in the preferred embodiment of the present inventionusers access Trade Manager 150 using standard browsers and the Internet.One of the significant aspects and advantages of the present inventionis that through the use of the Internet, geographically distributedparties to the transactions can each log onto Trade Manager 150 andinstantly determine the status of a particular transaction. This is aquantum leap of innovation over the prior art in which determining thestatus of the transaction often involves several phone calls or faxesover several different time zones.

In parallel to the population of the Trade Manager 150 database, asimilar database in TradeDoc 100 is populated with the transaction data.In the preferred embodiment, each of Financial System 175, Trade Manager150 and TradeDoc 100 maintain their own separate databases. Onetechnical reason for this implementation is that performance is enhancedwith separate databases since a load on the database by one system doesnot impact use of the database by the other systems. One requirement ofmaintaining separate databases is that the data in each of the databasesmust be synchronized. One other reason for maintaining separatedatabases is the each of the systems Financial System 175, Trade Manager150 and TradeDoc 100 can be operated separately and independently. Forexample, some Sellers 100 might want to use only TradeDoc 100 formanaging their own internal processes without the need for any of thefunctions provided by Financial System 175 or Trade Manager 150. In thisembodiment, a facility incorporating just TradeDoc 100 and its separatedatabase can be established for this Seller 100. In an alternativeembodiment, a single common database can be provided for FinancialSystem 175, Trade Manager 150 and TradeDoc 100. In this embodiment, nosynchronization of data is required, but there may be performanceimpacts as described above. However, in a small site, all of thedatabase can be combined into a single database.

As briefly described above, TradeDoc 100 is a tool for managing thetrade process from the period from the advice of the L/C and/or PO to teSeller 120, to the point of the collection of the payment for deliveredgoods. As described above, certain Sellers 120 can have an agreementwith the bank to use TradeDoc 100 to generate trade documentationwithout the bank having the capacity as either the issuing or advisingbank. This is possible since TradeDoc 100 is typically operated by thedocument preparation unit of the bank, which is a separate from the L/Cdepartment which manages the Financial System 175. Furthermore, a Buyer130 can mandate in its agreement with the Seller 120 that the Seller 120use TradeDoc 100 in managing its documentary processes. TradeDoc 100 canhave the same information as Trade Manager 150 for those Sellers 120that are the recipient of the L/Cs or POs directly from the Buyer 130 orthe Buyer's 130 issuing bank or the Seller's 120 advising bank. In thisembodiment, both the TradeDoc 100 and Trade Manager 150 databases areupdated with the L/C and/or PO information supplied directly from theSeller 120 or from the advising or issuing bank. This includes anyamendments and payment information.

In the preferred embodiment illustrated in FIG. 2, TradeDoc 100 isoperated by the financial institution on behalf of its clients, theSellers 120, but access to the TradeDoc 100 system can be granted toother licensed users (e.g., Buyers 130) if the Seller 120 in thetransaction so desires. Some Sellers 120 would not want to let the Buyermonitor the internal status of the Seller's process, but some Buyer'smight on insist on such monitoring capability. A full description of theoperation of the TradeDoc 100 system is found below in connection withFIG. 3, but as generally depicted in FIG. 2, TradeDoc 100 generates allof the documentation required by the trade transactions and interactswith third parties such as forwarders, brokers, customs or othergovernment agencies, Shippers 250, Insurance Providers 260 and otherparties in the supply chain in order to ensure that the process flowssmoothly and is not held up due to incorrect or insufficientdocumentation.

FIGS. 3A and 3B illustrate the operation of TradeDoc 100 in assisting aSeller 120 in managing the process of generating the documentationrequired to complete the trade operation. As is further illustrated inthis Figure, TradeDoc 100 also assists the Seller 120 in its internalmanufacturing processes by ensuring the goods manufactured conform tothe L/C and or PO. Prior to describing the TradeDoc 100 process, a briefdiscussion of the database used by TradeDoc 100 is warranted. Thedatabase in TradeDoc 100 is similar to the database maintained in TradeManager 150. Each record in TradeDoc 100 preferably contains thefollowing fields: Issuing bank L/C number; Advising bank L/C number;Issuing bank name and address; Advising bank name and address;Beneficiary name and address; L/C currency; L/C amount; L/C issuingdate; L/C expiry date; L/C tenor; Latest shipment date; MerchandiseInventory; Tran-shipment allowable indicator; Partial shipment allowableindicator; Special Instruction; Reimbursement Instruction; and AmendmentNumber. As can be seen some of the fields in the TradeDoc 100 databaseare the same as in the Trade Manager 150 database (e.g., L/C number)while others (e.g., Tran-shipment allowable indicator) are only requiredfor the generation of documentation by TradeDoc 100 and are accordinglynot tracked by Trade Manager 150.

As TradeDoc 100 receives data for the fields described above withrespect to a trade transaction, it creates an L/C record in the TradeDoc100 database. From the terms of the L/C, TradeDoc 100 is able to createa list of the required documents as will be described below with respectto FIGS. 3A and 3B. In addition, TradeDoc 100 parses and breaks down theL/C terms and conditions into attributes and processing rules in orderto make the decision process with respect to document requirements moreautomated. In addition to an L/C record for each transaction, TradeDoc100 can create (based on the customer's standard instructions) one ormore ‘Sales Order’ record(s) from the ‘Merchandise Inventory’ datacontained in the L/C or PO (note one L/C or PO can have more than one‘Sales Order’ associated with it). As will be more fully describedbelow, TradeDoc 100 allows a Seller 120 to keep track of the transactionon the basis of its own Sales Orders, rather than the PO or L/C issuedby the Buyer 130. If the data originates from the Buyer 130, or theBuyer's issuing bank or advising bank, a Sales Order record is set upwith a status of pending since TradeDoc 100 requires that thebeneficiary (Seller 120) provide the details for the Sales Order record(e.g., such as ‘Sales Order Number’). If the data originates directlyfrom a Seller 120, the data is input and the status of the Sales Orderrecord is set to ‘Sales Order Confirmed’.

Reflecting the nature of commercial trading, amendments to L/Cs or POsoccasionally occur and TradeDoc 100 is accordingly able to process suchamendments. An amendment to an L/C or PO either comes directly from theBuyer 130 or the advising bank either in electronic or hardcopy form.Preferably, the amendment to the L/C or PO contains data for all of thefields as described above with respect to an original advisement of theL/C or PO. In an amended L/C or PO, the data reflects the amended terms.Upon receipt of the amended L/C or PO, TradeDoc 100 retrieves theoriginal L/C or PO record from the TradeDoc 100 database based on thefollowing matching criteria: Issuing Bank L/C number; Advising Bank L/Cnumber; and the status of the L/C is not ‘Cancel’. If no matching recordis found, or if the record is found but the wrong status is detected onthe matched L/C, the transaction is flagged on an exception report andprocess of amending the L/C is terminated. If the status of the L/C is‘Expired’ or ‘Bookoff’ and the ‘Expiry Date’ in the proposed amended L/Cis still earlier than the processing date, the transaction is flagged onan exception report and the amendment process is terminated pendingmanual rectification by TradeDoc 100 operators.

In processing an amended L/C or PO, TradeDoc 100 provides the followingvalidations: a newly added Sales Order should not exist; a deleted oramended Sales Order must exist; and each amended Sales Order isvalidated against all its related ‘Invoices’ (if any) to check theremaining balance. If the above validation fails, TradeDoc 100 caneither display a warning message and proceed with the process or displayan error message and terminates the processing pending manualrectification. As with original L/Cs, if the supplied data isincomplete, it must be manually repaired.

Once an amended L/C has been validated, the L/C record is updated basedon the amendment. Furthermore, the list or required documents (generatedfrom the L/C and/or PO) is updated based on the revised L/C terms ifneeded. This may mean adding new document to the list, deleting olddocument from the list and/or amending the number of copies required forany existing document on the list. Finally, the Sales Order record(s)are updated if the Merchandise Inventory of the L/C is amended. This maymean adding new Sales Orders, deleting old Sales Orders and/or amendingelement(s) of any existing Sales Orders. If the data for the amendedL/C/ came from anyone other than the Seller 120, any new or amendedSales Order must be confirmed by the Seller 120. Similar to amendments,TradeDoc 100 is capable of processing canceled L/Cs. It must be notedthat TradeDoc 100 only amends the trade documents generated pursuant tothe L/C and/PO or an amended L/C and/or an amended PO and does not amendthe PO or L/C itself.

Returning to FIGS. 3A and 3B, these Figures illustrate both the processexecuted by TradeDoc 100 as well as the interactions of TradeDoc 100with other systems (e.g., Trade Manager 150). The starting point for theprocess illustrated in these Figures is that the terms of the L/C and/orthe PO have been agreed upon and included in the TradeDoc 100 and TradeManager 150 databases, and it is presently the obligation of the Seller120 to manufacture and deliver the goods according to the agreementbetween the parties. The Seller 100 is advised of either the L/C or thePO electronically via Trade Manager 150 or TradeEDI 125.

As described above with respect the TradeDoc 100 database, the operativedocument from which the Seller 120 manufactures its goods is an internaldocument known a Sales Order. Although not specifically illustrated inthe Figures, TradeDoc 100 is capable of generating the Sales Order forthe Seller 120 from the L/C and/or PO. Alternatively, the Seller 120itself can generate the Sales Order. As shown in FIG. 3A, TradeDoc 100communicates with Trade Manager 150 in order to keep current the statusof the transaction as reported in Trade Manager 150. As milestones arereached in the process as described below, TradeDoc 100 provides TradeManager 150 with an updated status. As described above, this status isavailable to the Seller 120 and to the Buyer 130 if agreed to by theSeller 120 and the Buyer 130.

Once the Sales Order has been generated, either by the Seller 120 itselfor by TradeDoc 100, TradeDoc 100 in step 300 compares the details of theSales Order to the details of the L/C and/or PO. This comparison is toverify that the Sales Order from which the Seller 120 complies with allof the requirements of the L/C and/or PO. For example, the L/C mightrequire the manufacture and delivery of 1,000 units, while the Seller120 might have mistakenly generated a Sales Order specifying 10,000units. The check in step 300 will ensure that this type of mistake iscaught and corrected prior any further, potentially costly, actions bythe Seller 120.

Step 305 illustrates an optional function provided by TradeDoc 100. Inpractice, a Seller 120 may be in a position to provide financing,“supplier credit” to the buyer. If this is the case, the Seller checksthe availability of credit under a preset credit limit for thatparticular Buyer 130. Typically, a financial institution performs theactual monitoring of the availability of credit for the Buyer 130 anTradeDoc assists the financial institution in making this determinationby supplying the terms of the transaction. In step 305, the Sales Orderis used in the determination if financing is available. Although notillustrated in FIG. 3A, the determination with respect to financing iseither made by the bank operating TradeDoc 100 or by a third partysource of financing. The resulting financing determinating is reportedback to the Seller 120.

At the same time the Sales Order is provided to TradeDoc 100, the Seller120 provides the same Sales Order to its Manufacturing division 122.From the Sales Order, the Manufacturing arm 122 generates amanufacturing specification sheet from which its manufacturing employeeswill manufacture the actual goods. The Sales Order itself cannotefficiently be used by the manufacturing employees in their dailyoperations and planning functions. Although FIG. 3A specifies that theManufacturing division 122 generates a manufacturing specificationsheet, if the goods have already been manufactured and are in inventory(e.g., the Seller is a distributor and not a manufacturer), theManufacturing division 122 can provide an inventory pick sheet thatindicates the items which will be picked from inventory in order tosatisfy the Sales Order.

The manufacturing specification sheet is forwarded to TradeDoc 100 whichcompares the Sales Order with the manufacturing specification sheet.This comparison in step 310 detects any deviation between thedescription of the goods requested by the Buyer 130 (embodied in the POor L/C) and the description of the goods which the Manufacturingdivision 122 plans on making available in fulfillment of the Buyer's 130request. Again, the comparison of step 310 is intended to discover anyerrors in the documentation being used by the Seller 120. Such errorscan result in the manufacture of the wrong type or number of goods whichin turn results in lost profits for the Seller 120. For example, if theBuyer 130 has ordered 10,000 blue units and the Manufacturing division122 mistakenly manufactures 10,000 red units, the Seller 120 first ofall has to go back and manufacture the originally requested blue units,most likely resulting in a delay in shipment, but the Seller 120 isadditionally left with 10,000 red units in stock.

If TradeDoc 100 detects a discrepancy between the manufacturingspecification sheet and the Sales Order, it notifies the Seller'sproduction control 126. It is preferred that the matching step 310occurs before any required manufacturing or picking takes place. As thecomparison performed by TradeDoc 100 in step 310 is virtuallyinstantaneous, the Seller 120 must only ensure that the specificationsheet is generated and transmitted to TradeDoc 100 at some point beforemanufacturing begins. In step 320, the Seller's production control 126makes the corrections to the manufacturing specification sheet andforwards the corrected sheet back to TradeDoc 100 where a confirmationcomparison of the specification sheet is made with respect to the SalesOrder. If the same or additional errors are detected, an iterativeprocess can take place between TradeDoc 100 and the Seller 120′sproduction control 126 system or personnel. Once no discrepancies aredetected, the Manufacturing division 122 uses the verified manufacturingspecification sheet to commence and eventually complete themanufacturing of the goods.

After completion of the comparison of step 310, the matched Sales Orderis used by TradeDoc 100 to create shipping instructions (e.g., draftbill of lading or airway bill) in step 315. The process of arranging forthe shipment of the goods takes place in parallel to the process ofmanufacturing of the goods. The draft bill of lading or airway bill orother shipping instructions are generated from the TradeDoc 100 databasewhich includes, but is not limited to the following data with respect toshipping: Name of Applicant/Buyer 130; Currency; Amount; TenorInformation; Actual Shipment Date; Merchandise Inventory—Description andQuantity of Goods; Purchase Order/Contract Number; Name, Address andTelephone Numbers of the Third Party Documents, (e.g., InspectionCertificate, if any, Contact Person, if possible); and SpecialInstruction, if any. Prior to the present invention, the Seller 120 hadto manually generate the shipping instructions which again provided thepossibility of error, either human or systemic.

Once the shipping instructions document has been generated by theautomatic process in step 315, TradeDoc 100 transmits the shippinginstructions (e.g., packing lists) to the Freight Forwarder (Shipper)250 as illustrated in FIG. 3B. Again, in the preferred embodiment, theInternet is used as the communication media for the transmittal of theshipping instructions from TradeDoc 100 to the Freight Forwarder 250. Inresponse to the shipping instructions from TradeDoc 100, the Shipper 250returns a draft Bill of Lading (B/L). The B/L is the commercial documentused by Shippers 250 when transporting goods. In an alternativeembodiment of the present invention, TradeDoc 100 can generate the draftB/L which is then transmitted to the Shipper 250 for approval. Althoughnot separately illustrated in FIG. 3B, TradeDoc 100 in step 350 checksthe draft B/L from the Shipper 250 in order to verify that it conformswith the details of the shipping instructions previously generated byTradeDoc 100.

In step 350, TradeDoc 100 automatically generates a invoice using thematched order from step 310 (see FIG. 3A) and from a receivable updateor draft invoice from the Seller's 120 Accounting system 124 (see FIG.3A). As shown in FIG. 3A, the Seller 120′s Accounting department 124only generates the receivable update or draft invoice only after theSeller's Manufacturing department 122 has notified Accounting 124 thatthe manufacturing of the goods has been completed. The receivable updateor draft invoice reflects the goods that were actually manufactured bythe Manufacturing department 122. TradeDoc 100 verifies that thereceivable update or draft invoice from the Seller's 120 Accountingsystem 124 is in accordance with the matched Sales Order resulting fromstep 310. Again, this verification by TradeDoc 100 ensures that thereare no human or systemic errors in the receivable update or draftinvoice. If any errors are detected in the documentation from theAccounting System 124, they are corrected manually. Once TradeDoc 100has verified that the data from the Accounting department 124 iscorrect, TradeDoc 100 generates the actual invoice that forms part ofand is used to create the remainder of the documentation required tocomplete the trade transaction.

The invoice generated in step 350 is used by TradeDoc 100 in step 355 toautomatically generate an shipping insurance instruction. The shippinginsurance instruction necessarily contains the pertinent informationwith respect to the goods that are being sought to be insured. Theinsurance instruction is sent (again preferably through the Internet) toan Insurance Provider 390. The Insurance Provider 390 in turn generatesand transmits back to TradeDoc 100 the documentation evidencing theshipping insurance policy on the goods to be shipped.

In step 360, all of the final export documents required for completingthe trade transaction are automatically generated by TradeDoc 100 usingthe existing data in the TradeDoc 100 database, the invoice from step350, the final B/L from the Freight Forwarder 250 and the insurancedocument from the insurance Provider 390. The final formal documentsgenerated include, but are not limited to invoices, packing slips, B/L,insurance certificate and certificate of analysis for example. In somecases, customers will use independent certificate broker/agents tocertified the goods shipped, e.g. SGS. TradeDoc 100 provides them withthe list of good's from the invoice/packing slip and the inspection willprovide certified message after the inspection is completed. This can bedone on a electronic message or paper certificate/stamp marking.

In step 375, the documents generated in step 360, including the bill oflading or airway bill can be used by TradeDoc 100 to generate a requestfor receivables insurance. This request is forwarded to an insuranceprovider 390 which can be the same or a different insurance providerthat provided the shipping insurance. In step 365, TradeDoc 100 iscapable of forwarding the final documents to a broker or agent of theSeller 120 who requires advance knowledge of these documents. An examplewould be a local agent who is responsible for ensuring that the goodsclear customs. In step 370, TradeDoc 100 generates the service chargesto be applied to the Seller 120 for the services performed in generatingall of the formal paperwork. In a preferred embodiment, these servicecharges are presented to the Seller 100 in electronic form on one of itsworkstations. The presentation of the service charges includes a“Pay-it” button by which the Seller 120 can click on this button and theSeller's 120 account (e.g., a Demand Deposit Account) is automaticallydebited for the amount of the service charges.

In some countries like Hong Kong, the local government requires anyimports or exports to have a declaration be filed with the TradeDepartment of that country. Using all of the information already in theTradeDoc 100 database, TradeDoc 100 is able to generate such an exportdeclaration which can then be filed with the Hong Kong Trade Department(again, preferably through electronic communication means). In addition,textile export to the United States (U.S.) requires an export quotafiling. Once the interface is known, TradeDoc 100 is capable ofelectronically interfacing with the local government system in order tofile the required export documentation required by the local government.Textile Imports into the U.S. require a U.S. visa. TradeDoc 100 canautomatically generate the required documentation and interface witheither the U.S. custom system or a local government system that has aninterface with the US Custom system. For example, the Hong KongGovernment Trade Department has a link to the U.S. Custom system tofacilitate obtaining the required U.S. Visa. Some commodity exports,i.e., dairy products from Australia requires an Australian governmentagency to certify the product. TradeDoc 100 is capable of interfacingwith the proper government agency to obtain the electroniccertification. Commodity exporters are often required to provide acertificate of analysis to specify the quality/purity of the product,i.e. Aluminum. Again, TradeDoc 100 can interface with the exporter or athird party certifier in order to obtain the certificate of analysis.

The final step in the process is that all of the final exportdocumentation is transmitted to the issuing bank to start the collectionprocess. In the collection process, the final documentation must bepresented either to the Buyer 130 directly under and Open Accounttransaction or to the Buyer 130's bank (the issuing bank) under an L/Ctransaction. One significant advantage of the present invention is thatsince all of the final documentation is in electronic form, thedocuments may be printed (using the corporate intranet described above)at the location of the bank which is closest to either the Buyer 130 orthe Buyer 130's bank. This remote printing capability significantlyreduces the time required for presenting the papers for collection andtotally eliminates any possibility of the documentation becoming lost orotherwise mishandled. This additionally shortens the time forcollection. If the customer and banks are part of the network, thedocuments can be posted on the Web site for retrieval by the properparties specified on the L/C or purchase agreements.

FIG. 4 illustrates the collection process either on an Open Account orL/C transaction. The present invention assists a Buyer 130 in managingits accounts payables and a Seller 120 in managing its receivables. Onbehalf of the Buyer 130 the system will match the invoice to the PO andprovide an electronic file, or other format, to update the Buyer's 130internal accounting and record keeping systems. On behalf of the Seller120, the system will match an incoming payment from the Buyer 130 to anoutstanding invoice and provide an electronic file, or other format, toupdate the Seller's 120 internal accounting and record keeping systems.

As illustrated in FIG. 4, TradeDoc 100 electronically transmits all ofthe final trade documents to the Financial System 175 for paymentprocessing either on an Open Account or an L/C. The Financial System 175once again validates and checks the trade documents in step 420 toensure there are no discrepancies between the documents and the L/C orPO. If the bank operating the Financial System 175 is not the issuingbank, the trade documents are sent to issuing bank (not shown), eitherelectronically or in printed form, which in turn notifies the Buyer 130that payment is due. If the bank operating the Financial System 175 isthe issuing bank or maintains the Open Account for the Buyer 130, theFinancial System 175 notifies a Payment System 450 of the bank of thereceipt of the final trade documents. The Payment System 450 in turn,transmits a debit advice for the payment on an L/C to Trade Manager 150which forwards the advice for payment to the Buyer 130. As alternativelyshown in FIG. 4, the Seller 120 can itself advise the Buyer 130 of therequest for payment on an open account.

In parallel to the advice of payment, the Financial System 175 iscapable, if requested by the Buyer 130, of performing a reconciliationfunction on behalf of the Buyer 130. The reconciliation functionperformed by the Financial System 175 module matches the payment underthe trade documentation with the outstanding L/C or PO (under an OpenAccount transaction). Since an L/C may contain multiple POs and both POsand L/Cs may refer to multiple invoices this is not a trivial task. Thefile resulting from the reconciliation process is forwarded to theaccounting system of the Buyer 130 in order to complete/update itsaccounts payable records.

If the bank is the issuing bank or holds the open account, the Buyer 130provides Trade Manager 150 with an authorization for payment. Inresponse to this authorization for payment, the Payment System 450debits the Buyer's 130 account (e.g., DDA) and forwards the payment tothe Seller 120 or its bank 400. Again, as described above with respectto the service charges to the Seller 120, when the Trade Manager 150advises the Buyer 130 of the payment, Trade Manager 150 can incorporatea “Pay-it” button to facilitate the authorization of the payment to theSeller 120.

If the Seller 120 is customer of the bank, once payment is made byeither issuing or reimbursement bank, the payment is credited to theSeller's 120 account via the Financial System 175. The Payment System450 transmits the payment details along with any fees that have beendeducted to TradeDoc 100. TradeDoc 100 performs the function ofreconciling the payment with either invoice details or line items detailfor the Seller 120. The reconciliation function for the Seller 120 isperformed by TradeDoc 100 as opposed to the Financial System 175 becausethe reconciliation for the Seller 120 is performed on a line item basis.The details of the line items from the Seller's 120 invoice arepreferable maintained in the TradeDoc 100 database and not in thedatabase for the Financial System 175. Alternatively, the Financialsystem 175 can perform reconciliation for the Seller 120 if all of thedetailed information for the reconciliation is contained in theFinancial System 175 database. As with the procedure describe above withrespect to the Buyer 130, TradeDoc 100 transmits the reconciledinformation of receivable and fees to the Seller's 120 accounting systemfor updating it's receivable records. As described above, since the corebusiness of Sellers 120 is manufacturing and selling goods, thereconciliation function provided by the present invention is verydesirable.

One significant advantage of the present invention is that it can bepackaged and labeled (i.e., white labeled) such that the users of thesystem do not know who is actually operating the system. For example,the system may actually be operated by bank A, but the user interfacescreens can be designed such that the user believes the system is beingoperated by bank B. In this manner, bank B is able to present thisservice to its customers with a user interface consistent with itscorporate image and bank A enjoys the revenues it receives from bank Bfor the operation of the system. Furthermore, pieces of the presentinvention are able to be separately licensed and operated. For example,some Sellers 120 might only want the documentary functions provided byTradeDoc 100 and not require the Financial System 175, Trade Manager 150or TradeEDI functions.

Although the present invention has been described in relation toparticular embodiments thereof, many other variations and other useswill be apparent to those skilled in the art. It is preferred,therefore, that the present invention be limited not by the specificdisclosure herein, but only by the gist and scope of the disclosure.

1-41. (canceled)
 42. A system of processing trade documents associatedwith a trade operation between a buyer and a seller, the systemcomprising: an interface module receiving an initiation documentcontaining requirement information with respect to the trade operation;a database coupled to the interface module, the interface module mappingat least some of the requirement information into the database; and adocument generation module coupled to the database, the documentgeneration module automatically generating the trade documents utilizingthe requirement information contained in the database.
 43. The system asrecited in claim 42, wherein the initiation document is a purchase orderfrom the buyer.
 44. The system as recited in claim 42, wherein theinterface module is an electronic interface module that receives theinitiation document electronically.
 45. The system as recited in claim42, wherein the initiation document is an application for a Letter ofCredit from the buyer.
 46. The system as recited in claim 45, furthercomprising: a customer profile database, the customer profile databasecontaining standard terms and conditions used by the buyer; and a Letterof Credit generation module coupled to the customer profile database,the Letter of Credit generation module automatically generating theLetter of Credit using the standard terms and conditions contained inthe customer profile.
 47. The system as recited in claim 46, furthercomprising a repair module coupled to the Letter of Credit generationmodule, the database, and the customer profile database, the repairmodule repairing the Letter of Credit if there is a discrepancy betweenthe requirement information contained in the database and the standardterms and conditions contained in the customer profile.
 48. The systemas recited in claim 42, further comprising a tracking module coupled tothe database, wherein a status of the trade operation is maintained inthe database, the tracking module providing the buyer and seller accessto the database in order to view the status of the trade operation. 49.The system as recited in claim 48, wherein the tracking module iscoupled to the Internet and wherein the access to the database providedover the Internet.
 50. The system as recited in claim 48, wherein thetracking module is coupled to a private network and wherein the accessto the database is provided over the private network.
 51. The system asrecited in claim 48, wherein the tracking module is coupled to a dial upline, and wherein the access to the database is provided over the dialup line.
 52. The system as recited in claim 48, wherein tracking moduleis coupled to the interface module and wherein the interface moduleprovides secure access to the database.
 53. The system as recited inclaim 52, wherein the secure access is provided by encryption,authentication an non-repudiation.
 54. The system as recited in claim42, wherein the initiating document is an application for a Letter ofCredit, the system further comprising: a purchase order storage facilitycoupled to the interface module and coupled to the Letter of Creditgeneration module, the purchase order storage facility storing multiplepurchase orders received from the buyer through the interface module,and wherein the Letter of Credit generation module automaticallygenerates the Letter of Credit using the multiple purchase orders storedin the purchase order storage facility.
 55. The system as recited inclaim 42, wherein the document generation module generates a sales orderin response to the initiation document.
 56. The system as recited inclaim 55, wherein the document generation module generates the salesorder using the requirement information contained in the database. 57.The system as recited in claim 55, further comprising a creditverification module coupled to the document generation module, whereinthe credit verification module determines the availability of credit forthe buyer using the sales order if the seller desires to extend creditto the buyer with respect to the trade operation.
 58. The system asrecited in claim 56, further comprising a comparison and correctionmodule coupled to the document generation module and coupled to thedatabase, the comparison and correction module comparing the sales orderto the requirement information contained in the database in order todetermine any discrepancies, the comparison and correction modulecorrecting the sales order if there are any discrepancies, therebygenerating a matched sales order.
 59. The system as recited in claim 58,wherein the document generation module further generates manufacturingspecification sheet using the sales order, the comparison and correctionmodule comparing the manufacturing specification sheet to the matchedsales order in order to determine any discrepancies, and the comparisonand correction module further correcting the manufacturing specificationsheet if there are any discrepancies, thereby generating a matchedmanufacturing specification sheet.
 60. The system as recited in claim58, wherein the document generation module is coupled to the interfacemodule and wherein the document generation module further generatesshipping instructions using the matched sales order, and wherein theinterface module transmits the shipping instructions to a shipper. 61.The system as recited in claim 58, wherein the document generationmodule further generates an invoice.
 62. The system as recited in claim61, wherein the comparison and correction module compares the invoice tothe matched sales order in order to determine any discrepancies andcorrects the invoice if there are any discrepancies, thereby generatinga matched invoice.
 63. The system as recited in claim 62, wherein thedocument generation module generates required trade documents using thematched invoice.
 64. An automated method for a buyer to pay a seller viaa funding provider, wherein the method is executed by a programmedcomputer processor which communicates with the buyer and the seller viaa network, the method comprising the steps of: using at least onecomputer processor, a buyer establishing a funding agreement with afunds provider to fund an order placed by the buyer with a seller;transmitting, from the buyer and over at least one network, an ordermessage to the seller, the order message including at least an order bythe buyer for an item from the seller; receiving, by the buyer and overthe at least one network, a shipping notification from the seller inresponse to the order message, the shipping notification indicating thatthe order has been filled; after the shipping notification is receivedby the buyer from the seller, transmitting, by the buyer and over the atleast one network, a payment message to make a first payment to theseller for the order using funds from the funds provider; and paying, bythe buyer to the funds provider, a second payment.
 65. The method ofclaim 64, wherein the first payment is discounted.
 66. The method ofclaim 64, wherein the second payment further comprises the first paymentand a service charge.